System for broadcasting to, and programming, a mobile device in a protocol

ABSTRACT

The present invention is directed, in one embodiment, to a programming interface which enables device/protocol/network independent transmission of messages to, and programming of, mobile devices. In another embodiment, the present invention is directed to data structures maintained on, and supported by, the mobile devices. The present invention also, in another embodiment, provides security for programming messages and an acknowledgement channel over which the mobile device can acknowledge receipt of, and successful implementation of, a programming message.

REFERENCE TO CO-PENDING APPLICATION

[0001] The present application claims priority from U.S. provisionalapplication Ser. No. 60/070,720 filed on Jan. 7, 1998 entitled FEATURESOF TRANSMISSION AND MANIPULATION OF DATA and Ser. No. 60/075,123 filedFeb. 13, 1998 entitled FEATURES OF A COMMUNICATION CHANNEL and Ser. No.60/074,236 filed Feb. 10, 1998 entitled FEATURES OF DEVICE DRIVER.

[0002] The present invention hereby fully incorporates by reference U.S.application entitled SYSTEM FOR EFFICIENT ROUTING AND TRANSLATION OFDATA, Ser. No. ______ filed on even date herewith.

BACKGROUND OF THE INVENTION

[0003] The present invention relates to personal mobile computingdevices commonly known as mobile devices. More particularly, the presentinvention relates to a system and method for delivering information to,and programming mobile devices.

[0004] Mobile devices are small electronic computing devices oftenreferred to as personal digital assistants. Many such mobile devices arehand held devices, or palm size devices, which comfortably fit withinthe hand. One commercially available device is sold under the tradenameHandHeld PC (or H/PC) having software provided by Microsoft Corporationof Redmond, Wash.

[0005] Generally, the mobile device includes a processor, random accessmemory (RAM), and an input device such as a keyboard and a display. Thekeyboard can be integrated with the display, such as when the keyboardis incorporated as a touch sensitive display. A communication interfaceis optionally provided and is commonly used to communicate with thedesktop computer. A replaceable or rechargeable battery powers themobile device. Optionally, the mobile device can receive power from anexternal power source that overrides or recharges the built-in battery.

[0006] In some prior applications, the mobile device is used inconjunction with the desktop computer. For example, the user of themobile device may also have access to, and use, a desktop computer atwork or at home or both. The user typically runs the same types ofapplications on both the desktop computer and on the mobile device.Thus, it is quite advantageous for the mobile device to be designed tobe coupled to the desktop computer to exchange information with, andshare information with, the desktop computer.

[0007] Another technique for providing information to such mobiledevices is through a wireless transmission link. Such information caninclude electronic mail or news, weather, sports, traffic and localevent information. The information is typically obtained from a desktopcomputer connected to the Internet and delivered over a wiredconnection. However, it may be desirable to deliver such informationover a wireless connection as well. A wireless receiver on the mobiledevice can act to receive information as it is being sent to the mobiledevice.

[0008] Where the mobile device is or has a pager, each pager in a givensystem has one or more addresses. When a message is transmitted over awireless channel, it is destined for an address. All pagers assigned tothat wireless channel receive the message and check the addresscontained in the message against its own addresses. Thisaddress-matching algorithm can be implemented either in the hardware, orin software, or in a combination of hardware and software. If theaddress associated with the incoming message does not match any of theaddresses on the pager, then the message is discarded. However, if theaddress does match one of the addresses on the pager, then the messageis accepted and forwarded to higher level software in the protocol stackon the pager for suitable processing.

[0009] Addresses can typically be of two types. The first is a personaladdress which is unique within a given wireless network (i.e., only onepager has that address). The personal address is used for sending amessage to a particular pager.

[0010] The second type of address is a broadcast address. A broadcastaddress is typically programmed into many pagers within a given wirelessnetwork. Thus, a single message delivered over a broadcast address isreceived and accepted by multiple pagers in the network. Such addressesare used for implementing broadcast services, such as the news, traffic,weather, etc. services mentioned above.

[0011] There is currently no convenient way to reprogram the addressesin mobile devices, such as pagers. Instead, the pagers must be broughtback to a service center where special tools are used to access andmodify the internal storage of the pager, where the addresses arestored. Some prior systems have attempted to accomplish over-the-airprogramming. In such systems, the network owner (or carrier) sends aspecial message to the pager that changes the addresses in the pager.

[0012] However, to date, this has been quite uncommon. Each manufacturerof pagers has its own proprietary message formats and methods in theradio hardware and software associated with the pager. Thus, a specialmessage needs to be specially formatted for the reprogramming of each ofthe different manufacturers' pagers. In addition, some manufacturershave more than one model or style of pager, each with its own internalproprietary message formats and methods. Thus, even a singlemanufacturer of pagers would be required to have a variety of specialprogramming messages sent, based upon the particular type of pager beingused by the user.

[0013] Further, over-the-air programming presents significantdifficulties with respect to security. In other words, if the providerof the broadcast services being programmed wishes to charge users a feeor subscription price to receive the broadcast services, then theprogramming messages must be highly secure. Otherwise, unauthorizedprogramming of the pager devices to receive the broadcast services wouldbe problematic.

[0014] Further, with the advent of global computer networks, such as theInternet, and information, broadcast services, have become prevalent andimportant. However, a typical pager can only have a limited number ofaddresses (usually 2-8). A much larger number of broadcast serviceswould desirably be offered to suit a wide range of interests and needsfor the various users of the pagers. That being the case, eachindividual user would need to have the pager reprogrammed (by taking itback to a service center) so that it contained the addresses which wouldselect desired broadcast services, desired by the individual user. Thiswould need to be done each time the user wished to add, delete, orchange the broadcast services selection. This is highly cost inefficientand is believed to have at least stunted the growth and proliferation ofsuch broadcast services.

[0015] Over-the-air programming also presents another significanthurdle—reliability. For instance, even if a programming message were tobe transmitted over the air, the programming message could containerrors once received by the pager, or the pager could be out of theservice area, or turned off, when the programming message wastransmitted. In a one-way paging system (which is the most prevalentsystem in the world today) there is no way for a sender to know that theprogramming message was actually received successfully by the desiredpager.

SUMMARY OF THE INVENTION

[0016] The present invention is directed, in one embodiment, to aprogramming interface which enables device/protocol/network independenttransmission of messages to, and programming of, mobile devices. Inanother embodiment, the present invention is directed to data structuresmaintained on, and supported by, the mobile devices. The presentinvention also, in another embodiment, provides security for programmingmessages and an acknowledgement channel over which the mobile device canacknowledge receipt of, and successful implementation of, a programmingmessage.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 is a simplified block diagram illustrating one embodimentof a mobile device in a system in accordance with the present invention.

[0018]FIG. 2 is a more detailed block diagram of one embodiment of amobile device shown in FIG. 1.

[0019]FIG. 3 is a simplified pictorial illustration of one embodiment ofthe mobile device shown in FIG. 2.

[0020]FIG. 4 is a simplified pictorial illustration of anotherembodiment of the mobile device shown in FIG. 2.

[0021]FIG. 5 is a block diagram of one embodiment of a desktop computerin accordance with one aspect of the present invention.

[0022]FIG. 6 is a more detailed block diagram of an originator andmobile device in accordance with one aspect of the present invention.

[0023]FIG. 7 is a flow diagram illustrating over-the-air programming inaccordance with one aspect of the present invention.

[0024]FIG. 8 is a flow diagram illustrating programming of a mobiledevice using a global network, such as the Internet, or the World WideWeb.

[0025]FIGS. 9A and 9B illustrate a portion of an encryption scheme inaccordance with one aspect of the present invention.

[0026]FIGS. 10A and 10B illustrate another portion of an encryptionscheme in accordance with one aspect of the present invention.

[0027]FIGS. 11A and 11B illustrate the preparation of a programmingmessage in accordance with one aspect of the present

[0028]FIGS. 12A and 12B illustrate the processing of a programmingmessage on the mobile device in accordance with one aspect of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029]FIG. 1 illustrates a system 10 in which the present invention isillustratively implemented. System 10 includes content provider 12,wireless carrier 14, desktop computer 16 and mobile device 18. Contentprovider 12 provides any suitable type of data from a database or otherdata source. For example, content provider 12 is discussed hereinafteras a provider of wireless services or other types of services which maybe desired by a user of mobile device 18. Examples of such servicesinclude news, weather and sports services, stock quote services, trafficreport services, etc.

[0030] Wireless carrier 14 is described in greater detail later in theapplication. Briefly, however, wireless carrier 14 is configured toreceive service content and programming messages (hereinafter content)from content provider 12 via dial-up or direct internet connection, or anetwork connection. The way in which wireless carrier 14 obtainsinformation from content provider 12 can include proprietary ornon-proprietary means. For example, in one illustrative embodiment,wireless carrier 14 subscribes to active channels at a contentprovider's web site using the Internet Explorer product available fromMicrosoft Corporation. The Internet Explorer component pulls data fromthe web site and stores it on a cache for later transmission to mobiledevice 18.

[0031] Wireless carrier 14 also includes a wireless information server(WIS) 20. Server 20 has components which can pull data from contentprovider 12 as well. Server 20 also splits the content received fromcontent provider 12 into pieces which are compatible with the particulartype of transport being used by wireless carrier 14. For instance,server 20 may split the data such that it conforms to maximum packetsize constraints, character set requirements, etc. for the channel typeor transport type being used. Prior to transmission, the data ispreferably translated to a different form. As is described in greaterdetail later in the application, such translation may include variousforms of encryption, and may also include compression, encoding, etc.Once the data has been split appropriately such that it conforms to thetransport constraints, the data is then configured for transmission overthe air through a wireless network (such as through a paging channel) tobe received directly on mobile device 18. The transmitted data isreceived by a wireless receiver and driver component 22 on mobile device18 where the data is prepared for use by mobile device 18.

[0032] Mobile device 18 also preferably includes a modem 24. Thus,rather than being transmitted through wireless carrier 14, the servicecontent can be transmitted directly from content provider 12 through adirect dial-up modem connection to mobile device 18.

[0033] Desktop computer 16 will also be described in greater detaillater in the specification. Briefly, however, desktop computer 16 ispreferably provided with a standard web browser, such as InternetExplorer 4.0, commercially available from the Microsoft Corporation ofRedmond, Wash. That being the case, the users of desktop computer 16 canpreferably subscribe to channels in a standard fashion which provide theuser with certain channel content which can be browsed off-line oron-line. Desktop computer 16 can thus periodically retrieve or receivenew content for further transmission to mobile device 18.

[0034] Desktop computer 16 also preferably includes synchronizationcomponent 26. Briefly, synchronization component 26 is configured tointeract with a similar synchronization component 28 on mobile device 18such that files which are the subject of synchronization can besynchronized from desktop computer 16 to mobile device 18, or viceversa. Once synchronized, both files (those on computer 16 and mobiledevice 18) contain up to date information.

[0035] More specifically, mobile device 18, in the preferred embodiment,can be synchronized with either desktop computer 16, or another mobiledevice 18, or both. In that instance, properties of objects stored in anobject store on mobile device 18 are similar to properties of otherinstances of the same object stored in an object store on desktopcomplex 16 or another mobile device 18. Thus, for example, when a userchanges one instance of an object stored in an object store on desktopcomputer 16, the second instance of that object in the object store ofmobile device 18 is updated the next time mobile device 18 is connectedto desktop computer 16 so that both instances of the same object containup-to-date data. This is referred to as synchronization.

[0036] In order to accomplish synchronization, synchronizationcomponents 26 and 28 run on both mobile device 18 and desktop computer16 (or another mobile device 18). The synchronization componentscommunicate with one another through well defined interfaces to managecommunication and synchronization.

[0037] It is worth noting that, in the preferred embodiment, whilemobile device 18 can be coupled to desktop computer 16, it can be alsocoupled to another mobile device 18. This connection can be made usingany suitable, and commercially available, communication link and using asuitable communications protocol. For instance, in one preferredembodiment, mobile device 18 communicates with either desktop computer16 or another mobile device 18 with a physical cable which communicatesusing a serial communications protocol. Other communication mechanismsare also contemplated by the present invention, such as infra-red (IR)communication or other suitable communication mechanisms.

[0038]FIG. 2 is a more detailed block diagram of mobile device 18.Mobile device 18 preferably includes microprocessor 30, memory 32,input/output (I/O) components 34, desktop communication interface 36wireless receiver 37 and antenna 39. In a preferred embodiment, thesecomponents of mobile 10 are coupled for communication with one anotherover a suitable bus 38.

[0039] Memory 32 is preferably implemented as non-volatile electronicmemory such as random access memory (RAM) with a battery back-up module(not shown) such that information stored in memory 32 is not lost whenthe general power to mobile device 18 is shut down. A portion of memory32 is preferably allocated as addressable memory for program execution,while another portion of memory 32 is preferably used for storage, suchas to simulate storage on a disc drive.

[0040] Memory 32 includes operating system 40, an application program 42(such as a personal information manager or PIM) as well as an objectstore 44. During operation, operating system 40 is preferably executedby processor 30 from memory 32. Operating system 40, in one preferredembodiment, is a Windows CE brand operating system commerciallyavailable from Microsoft Corporation. The operating system 40 ispreferably designed for mobile devices, and implements database featureswhich can be utilized by PIM 42 through a set of exposed applicationprogramming interfaces and methods. The objects in object store 44 arepreferably maintained by PIM 42 and operating system 40, at leastpartially in response to calls to the exposed application programminginterfaces and methods.

[0041] I/O components 34, in one preferred embodiment, are provided tofacilitate input and output operations from a user of mobile device 18.I/O components 34 are described in greater detail with respect to FIGS.3 and 4.

[0042] Desktop communication interface 36 is optionally provided as anysuitable communication interface. Interface 36 is preferably used tocommunicate with desktop computer 16, content provider 12, wirelesscarrier 14 and optionally another mobile device 18, as described withrespect to FIG. 1. Thus, communication interface 36 preferably includessynchronization components 28 for communicating with desktop computer 16and modem 24 for communicating with content provider 12. Wirelessreceiver and driver 22 are used for communicating with wireless carrier14.

[0043]FIG. 3 is a simplified pictorial illustration of one preferredembodiment of a mobile device 18 which can be used in accordance withthe present invention. Mobile device 18, as illustrated in FIG. 3, canbe a desktop assistant sold under the designation H/PC having softwareprovided by the Microsoft Corporation. In one preferred embodiment,mobile device 18 includes a miniaturized keyboard 43, display 45 andstylus 46. In the embodiment shown in FIG. 3, display 45 is a liquidcrystal display (LCD) which uses a contact sensitive display screen inconjunction with stylus 46. Stylus 46 is used to press or contact thedisplay 45 at designated coordinates to accomplish certain user inputfunctions. Miniaturized keyboard 43 is preferably implemented as aminiaturized alpha-numeric keyboard, with any suitable and desiredfunction keys which are also provided for accomplishing certain userinput functions.

[0044]FIG. 4 is another simplified pictorial illustration of the mobiledevice 18 in accordance with another preferred embodiment of the presentinvention. Mobile device 18, as illustrated in FIG. 4, includes someitems which are similar to those described with respect to FIG. 3, andare similarly numbered. For instance, mobile device 18, as shown in FIG.4, also includes touch sensitive screen 45 which can be used, inconjunction with stylus 46, to accomplish certain user input functionswhen mobile device 18 is implemented as a pager, screen 45 is not touchsensitive and stylus 46 is not needed.

[0045] It should be noted that the display 45 for the mobile device asshown in FIGS. 3 and 4 can be the same size as one another, or differentsizes from one another, but would typically be much smaller than aconventional display used with a desktop computer. For example, displays45 shown in FIGS. 3 and 4 may be defined by a matrix of only 240×320coordinates, or 160×160 coordinates, or any other suitable size.

[0046] The mobile device 18 shown in FIG. 4 also includes a number ofuser input keys or buttons (such as scroll buttons 47) which allow theuser to scroll through menu options or other display options which aredisplayed on display 45, or which allow the user to change applicationsor select user input functions, without contacting display 45. Inaddition, the mobile device 18 also shown in FIG. 4 also preferablyincludes a power button 49 which can be used to turn on and off thegeneral power to the mobile device 18.

[0047] It should also be noted that, in the embodiment illustrated inFIG. 4, mobile device 18 includes a hand writing area 51. Hand writingarea 51 can be used in conjunction with stylus 46 such that the user canwrite messages which are stored in memory 42 for later use by the mobiledevice 18. In one illustrative embodiment, the hand written messages aresimply stored in hand written form and can be recalled by the user anddisplayed on the display screen 45 such that the user can review thehand written messages entered into the mobile device 18. In anotherpreferred embodiment, mobile device 18 is provided with a characterrecognition module such that the user can enter alpha-numericinformation into mobile device 18 by writing that alpha-numericinformation on area 51 with stylus 46. In that instance, characterrecognition module in the mobile device 18 recognizes the alpha-numericcharacters and converts the characters into computer recognizablealpha-numeric characters which can be used by the application programs42 in mobile device 18.

[0048] Of course, where mobile device 18 is implemented as a pager,stylus 46 and handwriting area 51 are not needed. Instead, mobile device18 is simply provided with screen 45, user input buttons 47 and powerbutton 49, or other suitable items.

[0049]FIG. 5 and the related discussion are intended to provide a brief,general description of a suitable desktop computer 16 in which portionsof the invention may be implemented. Although not required, theinvention will be described, at least in part, in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a personal computer 16 or mobile device 18. Generally,program modules include routine programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat desktop computer 16 may be implemented with other computer systemconfigurations, including multiprocessor systems, microprocessor-basedor programmable consumer electronics, network PCs, minicomputers,mainframe computers, and the like. The invention may also be practicedin distributed computing environments where tasks are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, program modules may belocated in both local and remote memory storage devices.

[0050] With reference to FIG. 5, an exemplary system for implementingdesktop computer 16 includes a general purpose computing device in theform of a conventional personal computer 16, including processing unit48, a system memory 50, and a system bus 52 that couples various systemcomponents including the system memory 50 to the processing unit 48. Thesystem bus 52 may be any of several types of bus structures including amemory bus or memory controller, a peripheral bus; and a local bus usingany of a variety of bus architectures. The system memory 50 includesread only memory (ROM) 54 a random access memory (RAM) 55. A basicinput/output system (BIOS) 56, containing the basic routine that helpsto transfer information between elements within the desktop computer 16,such as during start-up, is stored in ROM 54. The desktop computer 16further includes a hard disk drive 57 for reading from and writing to ahard disk (not shown) a magnetic disk drive 58 for reading from orwriting to removable magnetic disk 59, and an optical disk drive 60 forreading from or writing to a removable optical disk 61 such as a CD ROMor other optical media. The hard disk drive 57, magnetic disk drive 58,and optical disk drive 60 are connected to the system bus 52 by a harddisk drive interface 62, magnetic disk drive interface 63, and anoptical drive interface 64, respectively. The drives and the associatedcomputer-readable media provide nonvolatile storage of computer readableinstructions, data structures, program modules and other data for thedesktop computer 16.

[0051] Although the exemplary environment described herein employs ahard disk, a removable magnetic disk 59 and a removable optical disk 61,it should be appreciated by those skilled in the art that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks (DVDs), Bernoulli cartridges, random access memories (RAMs), readonly memory (ROM), and the like, may also be used in the exemplaryoperating environment.

[0052] A number of program modules may be stored on the hard disk,magnetic disk 59, optical disk 61, ROM 54 or RAM 55, including anoperating system 65, one or more application programs 66 (which mayinclude PIMs), other program modules 67 (which may includesynchronization component 26), and program data 68. A user may entercommands and information into the desktop computer 16 through inputdevices such as a keyboard 70, pointing device 72 and microphone 74.Other input devices (not shown) may include a joystick, game pad,satellite dish, scanner, or the like. These and other input devices areoften connected to the processing unit 48 through a serial portinterface 76 that is coupled to the system bus 52, but may be connectedby other interfaces, such as a sound card, a parallel port, game port ora universal serial bus (USB). A monitor 77 or other type of displaydevice is also connected to the system bus 52 via an interface, such asa video adapter 78. In addition to the monitor 77, desktop computers maytypically include other peripheral output devices such as speaker 75 andprinters.

[0053] The desktop computer 16 may operate in a networked environmentusing logic connections to one or more remote computers (other thanmobile device 18), such as a remote computer 79. The remote computer 79may be another personal computer, a server, a router, a network PC, apeer device or other network node, and typically includes many or all ofthe elements described above relative to desktop computer 16, althoughonly a memory storage device 80 has been illustrated in FIG. 4. Thelogic connections depicted in FIG. 4 include a local area network (LAN)81 and a wide area network (WAN) 82. Such networking environments arecommonplace in offices, enterprise-wide computer network intranets andthe Internet.

[0054] When used in a LAN networking environment, the desktop computer16 is connected to the local area network 81 through a network interfaceor adapter 83. When used in a WAN networking environment, the desktopcomputer 16 typically includes a modem 84 or other means forestablishing communications over the wide area network 82, such as theInternet. The modem 84, which may be internal or external, is connectedto the system bus 52 via the serial port interface 76. In a networkenvironment, program modules depicted relative to desktop computer 16,or portions thereof, including synchronization component 26, may bestored in local or remote memory storage devices. It will be appreciatedthat the network connections shown are exemplary and other means ofestablishing a communications link between the computers may be used.

[0055] Desktop computer 16 runs operating system 65 that is typicallystored in non-volatile memory 54 and executes on the processor 48. Onesuitable operating system is a Windows brand operating system sold byMicrosoft Corporation, such as Windows 95 or Windows NT, operatingsystems, other derivative versions of Windows brand operating systems,or another suitable operating system. Other suitable operating systemsinclude systems such as the Macintosh OS sold from Apple Corporation,and the OS/2 operating system sold by International Business Machines(IBM) of Armonk, N.Y. Application programs are preferably stored inprogram module 67, in volatile memory or non-volatile memory, or can beloaded into any of the components shown in FIG. 5 from a floppy diskette59, CDROM drive 61, downloaded from a network via network adapter 83, orloaded using another suitable mechanism.

[0056] A dynamically linked library (DLL), comprising a plurality ofexecutable functions is associated with PIMs in the memory for executionby processor 48. Interprocessor and intercomponent calls are facilitatedusing the component object model (COM) as is common in programs writtenfor Microsoft Windows brand operating systems. Briefly, when using COM,a software component such as a DLL has a number of interfaces. Eachinterface exposes a plurality of methods, which can be calledindividually to utilize different services offered by the softwarecomponent. In addition, interfaces are provided such that methods orfunctions can be called from other software components which optionallyreceive and return one or more parameter arguments.

[0057] In general, the DLL associated with the particular PIM or otherprogram is designed specifically to work in conjunction with that PIMand to expose desktop synchronization interfaces that function asdescribed in more detail in the above-referenced co-pending U.S. patentapplication according to a synchronization protocol. The DLL, in turn,calls interfaces exposed by the PIM in order to access data representingindividual properties of objects maintained in an object store. Theobject store 6, of course, can reside in any one of the suitable memorycomponents described with respect to FIG. 4.

[0058]FIG. 6 is a more detailed block diagram of an originator 200, anda mobile device 18 which illustrates programming of mobile device 18 inaccordance with one aspect of the present invention. It should be notedthat originator 200 can be any source of programming information, suchas content or service provider 12, or a wireless carrier 14, or anyother suitable broadcast services provider. Originator 200 includescryptography component 202 and programming message originator component(PMOC) 204. FIG. 6 also illustrates transmission link 206 which linksoriginator 200 and mobile device 18. As described above, transmissionlink 206 can comprise a wireless transmission link, transmission throughsynchronization with a desktop computer and synchronization components26 and 28, transmission through a global computer network (such as theInternet), or another source via a modem, an intranet, or transmissionsimply through the transfer of a floppy disk containing the necessaryinformation.

[0059] Mobile device 18 is also illustrated in greater detail. Mobiledevice 18 includes radio hardware (or radio HW) 208 which corresponds tothe actual radio receiver hardware in mobile device 18. Mobile device 18also includes driver 210 which interfaces with radio HW 208 to passinformation to radio HW 208 and receive information from radio HW 208.Device 18 also includes programming message processing component (PMPC)212 which can be implemented in any suitable memory in mobile device 18.PMPC 212 receives messages transmitted over transmission link 206 andprocesses them in accordance with the techniques described below.

[0060]FIG. 7 is a flow diagram illustrating programming of mobile device18 in accordance with one aspect of the present invention. FIG. 7 willbe described also with reference to FIG. 6. FIG. 7 specificallyillustrates a system by which mobile device 18 is programmed usingover-the-air programming. First, PMOC 204 on originator 200 receives thedesired programming data to program mobile device 18. This is indicatedby block 214.

[0061] PMOC 204 then accesses cryptography component 202 and creates asigned and encrypted programming message for transmission overtransmission link 206 to mobile device 18. Encryption of the programmingdata into an encrypted programming message can be accomplished in anynumber of suitable ways. One method by which the encryption isimplemented is described in greater detail below with respect to FIGS.9A-11B. Encryption of the programming data into an encrypted programmingmessage is indicated by block 216. The data can also be subjected toadditional processing, such as compression, encoding, etc.

[0062] Next, the data is transmitted from originator 200 to mobiledevice 18. As described with respect to FIG. 6, the data can betransmitted over any suitable transmission link. With respect to theembodiment described in FIG. 7, transmission link 206 is a wirelesstransmission link, such as a radio frequency paging channel in whichPMOC 204 provides the encrypted programming message to a radiotransmitter which transmits it to radio HW 208 of mobile device 18,where the message is received. Transmission of the encrypted programmingmessage to mobile device 18 is illustrated by block 218 in FIG. 7.

[0063] As is described in greater detail below, the encryptedprogramming message has a header appended thereto. The message is passedto a message router component which routes the message to PMPC 212 andthrough various processing steps. The header indicates the types ofprocessing the message was subjected to prior to transmission, and themessage is subjected to complementary processing (such as decoding,decompression, etc.) after being received. Receiving the message isindicated by block 220.

[0064] The router passes the message to PMPC 212 on mobile device 18.This is indicated by block 222. PMPC 212 performs any necessarytranslations on the encrypted programming message. PMPC 212 alsodetects, based on the header information, that the message is aprogramming message and invokes an appropriate input/output (I/O)control call to place the message in proper form so that it can bepassed back to driver 210 in a desired format. In the preferredembodiment, PMPC 212 invokes I/O control calls to driver 210 usingappropriate application programming interfaces (APIs) which aredescribed in greater detail below. For example, the header informationmay identify that the programming message is a new address programmingmessage. In that case, PMPC 212 invokes a RADIO_PROGRAMMING I/O controlcall with a subparameter ADDRESS_PROGRAMMING to program a new address.The encrypted programming data is passed to driver 210 which calls alibrary function DecryptAndValidatePgmData( ) to decrypt and validatethe programming data Passage of the programming data, in the properform, to the driver 210 is illustrated by block 224.

[0065] After driver 210 has decrypted and validated the programmingmessage, the programming data is obtained in its original, unencryptedform. Driver 210 then places the actual programming data in appropriateoutput buffers in driver 210 for retrieval, or places them in inputbuffers on radio HW 208. Radio HW 208 can then perform the necessaryprogramming in accordance with the actual programming data provided.This is indicated by blocks 226 and 228.

[0066]FIG. 8 is a flow diagram illustrating programming of mobile device18 using over-the-web programming. First, a user of mobile device 18, inone exemplary embodiment, logs onto the web site of the broadcastservice provider of the services desired by the user. The user providesauthentication information at the web site of originator 200, from thedesktop computer 16. Such authentication information can, in oneexample, include the users name and the personal identification number(PIN) of the mobile device 18 for which programming is sought. This isindicated by block 230 in FIG. 8.

[0067] The user then requests a change in the subscription servicesreceived on mobile device 18. Such a change may include addition of aservice, deletion of a service or modification of a service and willlikely require reprogramming of the addresses, or other information,stored in mobile device 18, so that mobile device 18 can receive a newsubscription service, or so that a subscription service can be cancelledand no longer provided to mobile device 18. The user typically providesthis information from the desktop computer through which theoriginator's website has been accessed. This is indicated by block 232.

[0068] Originator 200 then creates a signed and encrypted programmingmessage for eventual transmission to mobile device 18. This is describedin greater detail below and is illustrated by block 234.

[0069] After the encrypted programming message is created at originator200, it is transmitted over transmission link 206 to mobile device 18.In the embodiment illustrated in FIG. 8, transmission link 206 comprisesan Internet connection between the user's desktop computer and thewebsite of the originator. Thus, the crypted programming message istransferred to the user's desktop computer, as illustrated by block 236.

[0070] The user then connects mobile device 18 to the desktop computer.As described above this type of connection can be formed in any suitablemanner, such as through a hardwire connection (or cable) using serialcommunication, through an infrared transmission link, or through anyother suitable connection mechanism. This is indicated by block 238.

[0071] The user then requests synchronization between the desktopcomputer and mobile device 18. As described above, synchronizationcomponents 26 and 28 interact according to a synchronization protocolwhich causes the encrypted programming message to be synchronized tomobile device 18. More specifically, synchronization component 28 causesthe encrypted message to be transferred to PMPC 212 on mobile device 18.The synchronization step is illustrated by block 240.

[0072] From this point, processing continues in exactly the same fashionas it did beginning with block 224 of the over-the-air programmingsystem set out in FIG. 7. Similar blocks are similarly numbered to thoseshown in FIG. 7. Specifically, PMPC 212 executes any translationsrequired on the encrypted programming message and places the encryptedprogramming message in proper form so that it can be passed to driver210. PMPC 212 then invokes I/O control calls to driver 210 usingappropriate APIs, in order to pass the encrypted programming messageback to driver 210 for decryption and validation. This is indicated byblock 224.

[0073] Once the data has been decrypted and validated by driver 210, theprogramming data, in its unencrypted form, is placed in appropriatebuffers. This is indicated by block 226.

[0074] Radio HW 208 then executes the programming operation according tothe programming data received by driver 210. This is indicated by block228.

[0075] It should be noted that the present system for programming theradio HW 208 on mobile device 18 is protocol, channel, and deviceindependent. In other words, once the encrypted programming message isprovided to PMPC 212, the process for providing that information todriver 210, and decrypting and validating the programming message atdriver 210 is exactly the same, regardless of what specific radio HWdevice 208 is provided, and regardless of the channel or transmissionprotocol over which the programming message was received.

[0076]FIGS. 9A and 9B illustrate a portion of the encryption schemeperformed by cryptography component 202 and PMOC 204 on originator 200.Of course, other suitable encryption schemes can be utilized, but FIGS.9A and 9B illustrate a portion of one illustrative encryption scheme.Specifically, FIGS. 9A and 9B illustrate the formation of an encryptionkey for use in the encryption scheme in accordance with one aspect ofthe present invention.

[0077] In order to obtain the encryption key, the present invention usesmessage specific data 242, base key 244, and encryption data 246. Themessage specific data 242 is preferably a part of the message itselfwith a required property that it changes with each programming messagebeing sent. Base key 244, in one illustrative embodiment, is theelectronic identification (EID) of mobile device 18. However, base key244 could also be any other key as well. Encryption data 246 ispreferably formed of other known bytes or data strings. The informationin blocks 242, 244 and 246 is provided to a hashed messagedauthentication code (HMAC) generator 248. HMAC generator 248 derives ahash value that is used for seeding or biasing a key derivationalgorithm. This biasing component is provided to key derivationcomponent 250, which acts upon the biasing component in order to derivean encryption key 252.

[0078]FIG. 9B is a flow diagram illustrating operation of the componentsshown in the block diagram of FIG. 9A. First, the message specific data242, the base key 244, and the encryption data 246 are obtained. This isindicated by blocks 254, 256 and 258. Next, the HMAC biasing componentis calculated. This is indicated by block 260. Finally, the biasingcomponent is used to derive the encryption key 254. This is indicated byblock 262. In one illustrative emboidment, the API CryptDeriveKey isused in order to derive the encryption key. The API CryptDeriveKey is astandard Windows API which derives a key for standard cryptographyalgorithms.

[0079] It should be noted that, since the message specific data 242changes with each message, the derived encryption key 252 will also bedifferent for each message. This is a preferred technique for derivingsuch a key. Without this technique, one can compare an encrypted messagewith a decrypted message and simply use those two items to compute thekey for subsequent messages. However, since the key changes with eachmessage, even if one key is derived, it cannot be used to decipher latermessages.

[0080]FIGS. 10A and 10B illustrate the generation of a signing key inaccordance with one aspect of the present invention. A number of itemsare Similalry numbered to those shown in FIGS. 9A and 9B, and aresimilarly numbered. As with the technique illustrated in FIG. 9A, anumber of components are used to form a signing key 266 in accordancewith the present invention. Message specific data 242, base key 244 andsigning string 264 are provided to HMAC generator 248. The messagespecific data 242 and base key 244 are described with respect to FIGS.9A and 9B above. The signing string 264 is similar to the encryptionstring 246. However, signing string 264 is formed of other known bytes,preferably formed as a data string. HMAC generator 248 again generates aseeding or biasing value which is provided to derive a signing key asillustrated by block 250. As with FIG. 9A, the signing key is preferablyformed using the CryptDeriveKey, standard Windows API in order toprovide signing key 266.

[0081]FIG. 10B is a flow diagram illustrating the operation of thecomponents shown in the block diagram of FIG. 10A. First, messagespecific data 242, base key 244 and signing data 264 are obtained. Thisis indicated by blocks 268, 270 and 272. Next, HMAC generator 248calculates the biasing component based on the input components. This isindicated by block 274.

[0082] The biasing component is then used to bias the signing keyderivation algorithm in order to obtain the signing key 266. This isindicated by block 276.

[0083] Once the signing key and encryption keys have been derived, theprogramming message can be prepared for transmission over transmissionlink 206. FIGS. 11A and 11B illustrate the preparation of theprogramming message for transmission over transmission link 206. Theprogramming data 278 and the signing key 266 are applied to HMACgenerator 248. This provides a signature value 280 which is based on theprogramming data 278 and the signing key 266. The digital signature 280is then added to programming data 278 as indicated by block 282. Theprogramming data 278, along with its signature 280, are then encryptedusing encryption key 252. In other words, the programming data 278,along with its signature 280, and encryption key 252, are provided toencryption component 282 and any suitable encryption technique can beused. The output of encryption component 282 is an encrypted message 284which corresponds to the programming data 278, along with its signature280, as encrypted by the encryption key 252.

[0084] The encrypted message 284 is appended to the message specificdata 242, in its unencrypted form (or plain text form). A header isadded to the encrypted message 284 and message specific data 242. Thisis indicated by block 286. The message can be further passed throughother translations such as compression, encoding, etc. The entireprogramming message 288 thus includes header 290, encrypted message 284,and message specific data 242. Header 290 is preferably a sequence ofbytes which serves a number of purposes. First, it identifies themessage 288 as a programming message. Next, it identifies the start andend of the encrypted portion 284 of the message, and the start and endof the message specific data portion 242 of the message (which is notencrypted). Finally, header 290 identifies whether the EID was used asthe base key.

[0085]FIG. 11B is a flow diagram illustrating the preparation of aprogramming message as described with respect to FIG. 11A. First, theprogramming message is obtained as indicated by block 292. Then thesigning key 266 is obtained. This is indicated by block 294. The HMACcomponent 282 is then run in order to obtain signature 280. This isindicated by block 296.

[0086] The programming data is then joined with its signature. This isindicated by block 298. The encryption key is obtained and theprogramming data, along with its signature, is encrypted using theencryption key in order to form the encrypted message. This is indicatedby blocks 300 and 302. The message specific data 242 is appended to theencrypted message, and a header is added in order to from the entireprogramming message transmitted over transmission link 206. Othertranslations can also be performed prior to transmission. These finalsteps are indicated by blocks 304 and 306.

[0087] The prepared message is transmitted over transmission link 206where it eventually ends up at PMPC component 212, as described above.Once the programming message is received by PMPC 212, it is placed inproper form for being passed to driver 210 and eventually radio HW 208,where the programming is actually carried out.

[0088]FIG. 12A is a more detailed block diagram of radio HW 208 anddriver 210 in order to illustrate the processing in those components.FIG. 12A illustrates that radio HW 208 preferably maintains a pluralityof data structures. The data structures illustrated in radio HW 208 inFIG. 12A are illustrated as tables. However, this is an exemplaryillustration only. Radio HW 208 is, in actuality, free to store the datain some other manner to optimize storage or speed of access.

[0089] Also, it is not necessary for radio HW 208 to store these datastructures at all. That may simply be a preferable implementation whenradio HW 208 is implemented as a removable hardware item (e.g., a radioPCMCIA type card). Storing the data structures on the radio HW 208 innon-volatile memory enables a user to remove the card from one mobiledevice 18 and plug it into another and carry the information easily tothe new device. It also allows for implementing more of the functions inthe radio hardware. However, device driver 210 can also store these datastructures in system memory and carry out the functions in software,although this may be less preferable in same respects.

[0090] In any case, FIG. 12A illustrates one embodiment in which radioHW 208 maintains key table 310, address table 312, group informationtable 314, group index table 316, and carrier and manufacturerinformation table 318. These data structures are fully described below.

[0091] Address Table

[0092] This table is used to store address related information. Expir-ey ation Address Address ddressN escrip- Status ndex Date Tag Info metion (1) 1) (2) (8) n) 32) * 64) * 0x01 401 PERSONAL 0x01 0 EXEC 0x01534 NEWS 0x00 0 (empty)

[0093] Status: This is a flag byte. The following are illustrativeflags: Flag Name Value Meaning ADDRESS_FLAG_(—) 0x01 If set, the addressis ENABLE enabled (message received on this address will be processed).If not set, messages received on this address are discarded by the card.ADDRESS_FLAG_(—) 0x02 If set, messages of this PRIORITY address shouldbe delivered to the higher levels immediately (e.g. personal address).If not set, the messages can be buffered internally for later delivery.ADDRESS_FLAG_AC_(—) 0x04 This address is enabled only ONLY when externalpower is available. ADDRESS_FLAG_PO_(—) 0x08 This address is enabledonly ONLY when the device is powered on. 0x10-0x80 Reserved for futureuse

[0094] KeyIndex: If non-0, index into the key table for the associatedkey. This key is used when a message arrives on this address that doesnot use any service group code.

[0095] ExpirationDate If non-0, it indicates the date on which thisaddress would be disabled. It is stored as, for example, number of daysfrom Jan. 1, 1997. Midnight is assumed (thus the expiration date is thelast day of the service). Note that card or the driver may not beexpected to act on this value—higher level applications will access andact on this value.

[0096] AddressTag: Tag for the address. The address tag is used onlyinternally for programming and accessing the addresses.

[0097] AddressInfo: This is the address and associated information forthe use of the underlying network (e.g. in FLEX system, this would bethe capcode and associated properties such as Collapse value, Phase,etc. In cellular systems, this would be the EIN (equipmentidentification number)).

[0098] AddressName: Descriptive name for the address (e.g. MSNBC,NewsNow, etc.).

[0099] Description: Descriptive text for the address (e.g. “Your stockand company news channel” ).

Overall Size=(1+1+2+8+32)*16=704 Bytes (For a Flex radio)

[0100] Key Table

[0101] This table is used to store security related information. This isillustratively a pooled resource as one or more service groups oraddresses can share the same key. KeyTag AlgCode Key (8) (4) (16)

Overall Size=(8+4+16)*16=448 bytes

[0102] Service Group Info. Table and Service Group Index Table

[0103] The service group table stores information on the service groups.Typically, look up for service group code and associated key is a morefrequent and time critical task than insertion or deletion of servicegroups. Thus, the driver preferably has a data structure designed toaccommodate this.

[0104] In the suggested implementation below, service group entries aresorted by address numbers and then by service group codes. A separateService group index table stores index for the last entry for any givenaddress. (It should be noted that his is simply one exampleimplementation. It is optimized for service group code look up and tominimize the storage requirement. It requires that each time a newservice group is defined, the table entries be shifted down to makespace for it. However, other suitable implementation can be used aswell.

[0105] In one illustrative embodiment, when an address is disabled, itsservice group entries are not removed or altered in anyway (however,since the card discards the messages for that address anyway, theseentries will not be used).

[0106] KeyIndex is the index into the Key Table that is associated withthis service group. Index 0 is reserved to mean “no key exists—thecontent for this service group is not encrypted”. Service ServiceService Expiration Group Group Descrip- Index Group Status Key-IndexDate Tag Name tion (1) Code (1) (1) (1) (2) (8) (32)* (64)* — 0x20 1 366Addr0Gp0

Addr0End 0x21 0x20 1 6 400 389 Addr0Gp1 Addr1Gp0

Addr1End 0x30 9 0 Addr2Gp0 . . . . . . AddrNGPN

AddrNEnd (empty) (empty) (empty) (empty)

[0107] ServiceGroupCode Service group code in the printable ASCII rangeof 0x20 and 0x7E.

[0108] Status: This is a flag byte. The following flags areillustratively defined: Flag Name Value Meaning GROUP_FLAG_(—) 0x01 Ifset, the service group is enabled ENABLE (message received on thisservice group will be processed). If not set, messages received on thisservice group are discarded by the driver. GROUP_FLAG_(—) 0x02 If set,messages of this service group PRIORITY should be delivered to thehigher levels immediately (e.g. Stock alert service group). If not set,the messages can be buffered internally for a later delivery.GROUP_FLAG_(—) 0x04 This service group is enabled only when AC_ONLYexternal power is available. GROUP_FLAG_PO_(—) 0x08 This service groupis enabled only when ONLY the device is powered on. 0x10- Reserved forfuture use 0x80

[0109] KeyIndex: If non-0, index into the key table for the associatedkey. This key is used when a message arrives on this service group code.

[0110] ExpirationDate If non-0, it indicates the date on which thisservice group would be disabled. It is stored, for example, as number ofdays from Jan. 1, 1997. A time 12:01 AM is assumed. Note that card orthe driver is illustratively not expected to act on this value—higherlevel applications will access and act on this value.

[0111] ServiceGroupTag: Tag for the service group. The service group tagis used only internally for programming and accessing the servicegroups.

[0112] ServiceGroupName: Descriptive name for the Service group (e.g.“International News”, “Local Weather”, etc.). Suggested size of thisfield is 32 but OEM can support more.

[0113] Description: Descriptive text for the service group (e.g. “Newsfrom all around the world that affects your little community”).Suggested size of this field is 64 but OEM can support more.

[0114] Index table is used to quickly locate a service group for a givenaddress.

Overall Size=(1+1+1+2+8)*64=832 (Service group table) (1)*16=16 (Indextable)=848 bytes

[0115]FIG. 12A also illustrates that driver 210 supports a librarycontaining certain functions that are generic to the system, but whichare preferably performed at the driver level for the sake of increasedefficiency or security. The support library is statically linked to theremainder of the driver components. The driver support libraryillustrated in FIG. 12A includes the AnalyzeMessage function 320, theDeriveEncryptionKey function 322 and the DecryptAndValidateRadioPgmDatafunction 324. These functions are described in detail later in theapplication.

[0116] Also, in the preferred embodiment, PMPC 212 is configured toinvoke a number of I/O control calls to perform various operations.Driver 210 supports and implements the I/O control calls according to apredefined syntax and operation which is also described below.

[0117] The general type definitions used in the driver API will now bedescribed. It should be noted that most of the following types mapsubstantially directly to the data structures described above, althoughthis is not necessary.

[0118] The following basic types are used:

[0119] BYTE Unsigned 8-bit

[0120] WORD Signed 16-bit

[0121] DWORD Signed 32-bit

[0122] TEXT String stored in a BYTE array. Since the length of thestring is usually available in another field, null termination is notrequired.

[0123] The following type definitions indicate illustrative minimum sizewhich the driver needs to support. The struct used in the API haveactual length in another field.

[0124] RADIO_TAG struct

[0125] TEXT Value[8] Tags are used to identify a particular address,service group, or key entry

[0126] RADIO_KEY struct

[0127] BYTE Value[16] Stores the encryption keys.

[0128] RADIO_NAME struct

[0129] TEXT Value[32] Stores carrier name, manufacturer name, Addressname, etc.

[0130] RADIO_DESC struct

[0131] TEXT Value[64] Stores description of the card, services,addresses, etc.

[0132] Complex Types (Structs)

[0133] All structures have the following two fields at the beginning:

[0134] WORD wStructSize Each struct has fixed size fields followed bythe length of the variable fields. The variable fields follow in thesame order as their lengths. The wStructSize field holds the size inbytes of the fixed part of the struct (i.e., fixed fields and thelengths of the variable fields). This field provides a versioning methodas well that will be used for backward compatibility in the futurereleases.

[0135] DWORD dwMemberValidMask A mask indicating which fixed size fieldsof the struct are valid and can be used (for variable size fields, alength of 0 indicates that the field is not present). This allows us touse the same struct even if some fields are not required. This isespecially useful when programming a single field within a structwithout changing the values of other fields.

[0136] In addition the variable length fields are grouped towards theend a length field for each one of them is provided. This allowsexpanding these structures without losing backward or forwardcompatibility. When accessing the variable length fields, the drivershould use the wStructSize field's value as the start offset for thefirst variable length field. This will allow for forward compatibiltywhen additional fields are added to the struct (using wStructSize fieldensures that these new fields will be ignored by the legacy drivers).

[0137] Although a wide variety of specific struct types are used in thenormal operation of the driver API, only those related to programmingare discussed herein. Such structs include the following:

[0138] Struct RADIO_ADDRESS

[0139] This struct contains information about the address.

[0140] DWORD dwMemberValidMask A mask indicating which fields of thestruct are valid. Construct the value by ‘OR’ing one or more of thefollowing:

[0141] 0x0001 AddressNumber field is valid

[0142] 0x0002 Status field is valid

[0143] 0x0004 ExpirationDate field is valid

[0144] BYTE AddressNumber Address entry number. Address entries arenumbered 0 onwards.

[0145] BYTE Status Status flags.

[0146] BYTE ExpirationDate[2] Expiration date. 0 if none.

[0147] BYTE AddressTagLen Length of the AddressTag field.

[0148] BYTE KeyTagLen Length of the KeyTag field.

[0149] BYTE AddressNameLen Length of the AddressName field

[0150] WORD wAddressDescriptionLen Length of the AddressDescriptionfield.

[0151] WORD wAddressInfoLen Length of the AddressInfo field.

[0152] RADIO_TAG AddressTag Address Tag.

[0153] RADIO_TAG KeyTag Associated key for this address. (If the fieldis not present, then no key is associated with the address).

[0154] RADIO_DESC AddressDescription Description for the address. Notethat this information is illustratively not required to be innon-volatile memory. It is displayed to the user for information purposeonly.

[0155] RADIO_ADDRESS AddressInfo Address and associated informationfields. This struct is protocol specific. For FLEX protocol it maycontain the capcode information encoding collapse value, phase, address,etc.

[0156] Sruct RADIO_GROUP

[0157] This struct contains information about the service group:

[0158] WORD wStructSize sizeof(RADIO_GROUP)

[0159] DWORD dwMemberValidMask A mask indicating which fields of thestruct are valid. Construct the value by ‘OR’ing one or more of thefollowing:

[0160] 0x0001 GroupNumber field is valid

[0161] 0x0002 Status field is valid

[0162] 0x0004 GroupCode field is valid

[0163] 0x0008 ExpirationDate field is valid

[0164] WORD wGroupNumber Service group number. Service groups arenumbered 0 onwards.

[0165] BYTE Status Status flags.

[0166] BYTE GroupCode Service group code

[0167] BYTE ExpirationDate[2] Expiration date. 0 if none.

[0168] BYTE GroupTagLen Length of the GroupTag field.

[0169] BYTE KeyTagLen Length of the KeyTag field.

[0170] BYTE AddressTagLen Length of the GroupTag field.

[0171] BYTE GroupNameLen Length of the GroupName field.

[0172] WORD wGroupDescriptionLen Length of the GroupDescription field

[0173] RADIO_TAG GroupTag Service group Tag.

[0174] RADIO_TAG KeyTag Associated key for this service group. (If thefield is not present, then no key is associated with the service group).

[0175] RADIO_TAG AddressTag Address this service group belongs to.

[0176] RADIO_DESC GroupDescription Description for the service group.Note that this information is not required to be stored in thenon-volatile memory. It is displayed to the user for information purposeonly.

[0177] Struct RADIO_KEY

[0178] This struct contains information about the encryption keys

[0179] BYTE KeyNumber Key number. Keys are numbered 1 onwards.

[0180] DWORD dwAlgCode Encryption algorithm code.

[0181] BYTE KeyTagLen Length of the KeyTag field.

[0182] BYTE KeyLen Length of the Key field.

[0183] RADIO TAG KeyTag Key Tag.

[0184] RADIO_KEY Key The encryption key.

[0185] struct RADIO_PGM

[0186] This struct is used for programming addresses, service groups,keys, etc.

[0187] WORD wStructSize sizeof(RADIO_PGM)

[0188] DWORD dwMemberValidMask A mask indicating which fields of thestruct are valid. Construct the value by ‘OR’ing one or more of thefollowing:

[0189] 0x0001 OperationCode field is valid

[0190] 0x0002 TypeCode field is valid

[0191] BYTE OperationCode Defines what operation to perform. Possiblevalues are:

[0192] 0x01 RADIO_PGM_OPERATION_PROGRAM program

[0193] 0x02 RADIO_PGM_OPERATION_UNPROGRAM unprogram

[0194] BYTE TypeCode Type of programming being performed. Possiblevalues are:

[0195] 0x01 RADIO_PGM_TYPE_CARRIER

[0196] RADIO_CARRIER struct follows.

[0197] 0x02 RADIO_PGM_TYPE_KEY

[0198] RADIO_KEY struct follows.

[0199] 0x03 RADIO_PGM_TYPE_ADDRESS

[0200] RADIO_ADDRESS struct follows.

[0201] 0x04 RADIO_PGM_TYPE_GROUP

[0202] RADIO_GROUP struct follows.

[0203] WORD wProgramDataLen Length of the ProgramData field.

[0204] WORD wCheckSumLen 2 (Length of the checksum field, not requiredbut defined for consistency's sake)

[0205] void ProgramData One of the following data structure (basedon-TypeCode):

[0206] RADIO_CARRIER CarrierInfo;

[0207] RADIO_ADDRESS AddressInfo;

[0208] RADIO_GROUP GroupInfo;

[0209] RADIO_KEY KeyInfo;

[0210] WORD wCheckSum Checksum of the entire struct except the checksumfield itself. Checksum is calculated by adding up the struct byte bybyte in a WORD and ignoring the overflow.

[0211] Struct RADIO_CRYPT

[0212] This struct is used for cipher functionality related IO controlcalls.

[0213] DWORD dwMemberValidMask A mask indicating which fields of thestruct are valid. Construct the value by ‘OR’ing one or more of thefollowing:

[0214] 0x0001 hCryptoProv field is valid

[0215] 0x0002 dwCryptoFlags field is valid

[0216] 0x0004 dwCryptoAlgId field is valid

[0217] HCRYPTPROV hCryptoProv handle to a Cryptography Service Provider

[0218] DWORD dwCryptoAlgId Cryptography Algorithm ID, e.g. CALG_RC4

[0219] DWORD dwCryptoFlags Flags for Cryptography functionCryptDeriveKey( ) e.g. CRYPT_EXPORTABLE

[0220] BYTE AddressTagLen Length of the AddressTag field

[0221] BYTE GroupTagLen Length of the GroupTag field

[0222] WORD wMsgSpecificDataLen Length of MsgSpecificData field.

[0223] RADIO_TAG AddressTag Address Tag

[0224] RADIO_TAG GroupTag Service group Tag

[0225] BYTE MsgSpecificData[ ] Message Specific Data

[0226] As stated above, the I/O control calls are made from PMPC 212 todriver 210 in order to accomplish certain operations. As with thevarious data structures, a variety of I/O control calls are supported inthe driver API. However, only those related to programming of driver 210and radio card 208 are discussed herein. I/O control calls have thefollowing syntax.

[0227] Syntax BOOL xxx_IOControl ( DWORD hOpenContext DWORD dwCode PBYTEpBufIn DWORD dwLenIn PBYTE pBufOut DWORD dwLenOut PDWORD pdwActualOut );

[0228] Parameters

[0229] hOpenContext Specifies a handle identifying the open context ofthe device. The xxx_Open function creates and returns this identifier.

[0230] dwcode Specifies a value indicating the I/O control operation toperform. These codes are device specific, and are usually exposed toapplication programmers by means of a header file.

[0231] pBufIn Points to the buffer containing data to be transferred tothe device.

[0232] dwLenIn Specifies the number of bytes of data in the bufferspecified for pBufIn.

[0233] pBufOut Points to the buffer used to transfer the output datafrom the device.

[0234] dwLenOut Specifies the maximum number of bytes in the bufferspecified by pBufOut

[0235] pdwActualOut Points to DWORD buffer the function uses to returnthe actual number of bytes received from the device.

[0236] Return Value

[0237] Returns TRUE if the device successfully completed its specifiedI/O control operation, otherwise it returns FALSE.

[0238] RADIO_PROGRAM

[0239] This IOCTL call allows the caller to program or un-program anaddress, service group, keys, or carrier information.

[0240] Syntax struct RADIO_PGM RadioPgm; BOOL xxx_IOControl ( DWORDhOpenContext DWORD dwCode = RADIO_PROGRAM PBYTE pBufIn = &RadioPgm DWORDdwLenIn = sizeof(RadioPgm) PBYTE pBufOut = NULL DWORD dwLenOut = 0PDWORD pdwActualOut = &dwWriteBytes ) ;

[0241] Operation

[0242] The driver programs or un-programs the given item. For securityreasons, the RadioPgm struct passed to this API is always encrypted. Thedriver should call the illustratively functionDecryptAndValidateRadioPgmData( ) included in the driver support libraryto decrypt and validate the input data.

[0243] Remarks

[0244] When performing a programming operation(RadioPgm.OperationCode=RADIO_PGM_OPERATION_PROGRAM), if the info structdoes not have all the required fields then the driver processes thecommand in the following manner:

[0245] 1. If the item being programmed already exists, change only thosefields that exist in the info struct. Fields that are missing in theinfo struct retain their old values. For example, when programming anaddress, if the address already exists and the field AddressDescriptionis missing in the info struct then the old value of this field isretained. This gives the ability to change the entire item or individualfields.

[0246] 2. If the item being programmed does not exist, then dependingupon the missing field, it should either take a default value or thewhole programming command should be rejected.

[0247] Programming a New Carrier Field Type Default dwFrequency RequiredUserID Required CarrierName Optional NULL CarrierDescri Optional NULLption Programming a new Address AddressNumber Optional (see below)AddressTag Required Status Required AddressDescript Optional NULL ionKeyTag Optional NULL ExpirationDate Optional 0x0000 Address Required

[0248] When programming a new address, AddressNumber is not required(the next available empty entry is used) but AddressTag isillustratively required. When changing an existing address, eitherAddressNumber or AddressTag can be used to refer to the desired address.If both are given then AddressNumber is used.

[0249] Programming a New Service Group Field Type Default WGroupNumberOptional (see below) GroupTag Required Status Required GroupDescriptionOptional NULL GroupCode Required KeyTag Optional NULL ExpirationDateOptional 0x0000 AddressTag Required

[0250] When programming a new service group, wGroupNumber is notrequired (the next available empty entry is used) but GroupTag isillustratively required. When changing an existing service group, eitherGroupNumber or GroupTag can be used to refer to the desired address. Ifboth are given then GroupNumber is used.

[0251] Programming a New Key Field Type Default KeyNumber OptionalKeyTag Required AlgCode Required Key Required

[0252] When programming a new key, KeyNumber is not required (the nextavailable empty entry is used) but KeyTag is required. When changing anexisting key, either KeyNumber or KeyTag can be used to refer to thedesired key. If both are given then KeyNumber is used.

[0253] RADIO_CRYPT_DERIVE_KEY

[0254] This IOCTL call allows the caller to program or un-program anaddress, service group, keys, or carrier information.

[0255] Syntax HCRYPTKEY hKey; BOOL xxx_IOControl( DWORD hOpenContextDWORD dwCode = RADIO_CRYPT_DERIVE_KEY PBYTE  pBufIn = &RadioCrypt DWORD dwLenIn = sizeof(RadioCrypt) PBYTE   pBufOut = &hKey DWORD  dwLenOut =sizeof(hKey) PDWORD  pdwActual Out = &dwWriteBytes ) ;

[0256] Operation

[0257] This IO control is used by the security component of the system.It is used to get a handle to a key. Since this requires access toElectroinc ID (EID) that should illustratively not be exposed outside ofthe driver. A function DeriveEncryptionKey( ) is illustratively providedin the driver support library and is discussed in greater detail belowto carry out the operation of this IO control. The driver should callthis function and pass the handle to the key (hKey) returned by it. Thisway, a security component can get a handle to the key without gettingaccess to the EID.

[0258] In order to implement the I/O control calls, driver 210 calls anumber of the functions stored in its support library. Such functionsare described below.

[0259] AnalyzeMessage( )

[0260] Syntax BOOL AnalyzeMessage ( void *pMsg DWORD dwMsgLen, BOOL*pDiscard BYTE *pServiceGroupCode); pMsg Pointer to the message bytes.dwMsgLen Length of the message. pDiscard Receives a BOOL valueindicating whether the message should be discarded or kept.pServiceGroupCode Receives the Service Group code.

[0261] Returns

[0262] Returns TRUE if service group code was found, FALSE otherwise.

[0263] Description

[0264] This function analyzes the message to determine if it has aservice group code. It may also analyze it for other characteristics tomake a determination if this message should be kept or discarded.

[0265] DeriveEncryptionKey( )

[0266] Syntax BOOL DeriveEncryptionKey ( RADIO_CRYPT *pCryptInput, BYTE*pbKeyVal{overscore (u)}e, DWORD dwKeySizeHCRYPTKEY *   phKey, ) ;

[0267] Some parameters to this function are provided by the caller, thedriver simply passes them to this function. The rest of the parametersare available to the driver in its internal data structure

[0268] pCrypt_Input Input to the RADIO_CRYPT_DERIVE_KEY IOCTL call.

[0269] pbKeyValue The key that needs to be used. based on the AddressTagand GroupTag fields within the RADIO_CRYPT structure (The caller to theIOCTL call provides these two fields, the driver needs to use them tolocate the key stored in the Key table and then pass the key in pbKeyparameter)

[0270] dwKeySize Number of bytes in the pbKeyValue parameter.

[0271] Returns

[0272] This function returns TRUE if the operation was successful, FALSEotherwise. If successful, it also returns a handle to the key producedfrom the given information.

[0273] Description

[0274] Encryption keys are illustratively derived based on one or moreof the following information: key associated with the address, keyassociated with the service group, message specific data, certain flags,and an algorithm ID. This function processes all this and produces ahandle to a key that can be used by the calling process to performencryption/decryption operations.

[0275] DecryptAndValidateRadioPgmData( )

[0276] Syntax BOOL DecryptAndValidateRadioPgmData ( PBYTE pInBuf =&RadioPgm DWORD dwInLen = sizeof(RadioPgm) PBYTE pKey = &ElectronicId(or Key) DWORD dwKeyLen = sizeof(ElectronicId) PBYTE pOutBuf =&DecryptedRadioPgm DWORD dwOutLen = sizeof (DecryptedRadioPgm) PDWORDpdwActualOut = &dwWriteBytes ) ; pInBuf Pointer to the input bufferholding the programming struct RADIO_PGM. dwInLen Size of theprogramming struct passed. pKey Pointer to the buffer holding key whichcould Electronic ID (EID) of the device or a valid key in the key tabledwKeyLen Size of Key passed. pOutBuf Pointer to the output buffer toreceive the decrypted struct. dwOutLen Size of the output buffer. Itmust be equal or greater than dwInLen. pdwActualOut Receives number ofbytes actually written into the output buffer.

[0277] Returns

[0278] This function returns TRUE if the input struct was a validstruct. The decrypted struct is placed in the output buffer. If thefunction finds that the data was not properly encrypted, it returnsFALSE and the driver should reject the programming command.

[0279] Description

[0280] The driver programming API require that the programminginformation passed to it is encrypted. This ensures that only theauthorized source can program the device. This function performs thedecryption and validation for the RADIO_PROGRAM IO control call of thedriver.

[0281]FIG. 12B is a flow diagram illustrating the operation of PMPC 212and driver 210 in programming radio HW 208. Initially, after suitabletranslations are performed, PMPC 212 is provided with the programmingmessage (via a message router) in one of the ways described above withrespect to FIGS. 7 and 8, or in any other suitable way. PMPC 212 thendetects, based on the header information, that the message is aprogramming message and invokes an appropriate IO control call to placethe information from the programming message in proper form, given thedata structures and the I/O control call syntax described above. This isindicated by block 326.

[0282] PMPC 212 then executes the RADIO_PROGRAM control call to driver210, supplying the Radio_Pgm struct, as described above. This isindicated by block 334.

[0283] In response to this control call, driver 210 calls theDecryptAndValidateRadioPgmData function 324 which is stored in thedriver support library. This function decrypts the program messageprovided in the RADIO_PROGRAM I/O control call. If this function findsthat the input struct was a valid struct, it returns a true value toPMPC 212 and places the decrypted struct in its output buffer for accessby radio HW 208. If this function finds that the struct was not properlyencrypted, it returns a false value and rejects the programming command.This is indicated by blocks 336 and 338.

[0284] A programming component configured to program the specific radioHW 208 being used then accesses the information in the output buffer ofdriver 210 and performs the desired programming function.

[0285] It should be noted that the actual programming data provided toradio HW 208 can be provided according to a proprietary form, and theactual programming of radio HW 208 can be done in accordance with anyproprietary parameters or constraints placed on it by the manufacturer.Thus, the manufacturer is free to define any programming operations, inaccordance with any proprietary method. However, by supporting theabove-defined data structures, radio HW 208 can be provided withproprietary programming data in an independent, open architecturefashion, regardless of the particular programming scheme used by radioHW 208, and regardless of the particular manner in which the programmingmessage is transmitted to mobile device 18.

[0286] Even given this device/protocol/network independence, oneobstacle still remains. There is currently no efficient method ofdetermining whether mobile device 18 actually received the programmingmessage, and has undertaken the requested programming operation. Thesystem in accordance with one embodiment of the present inventionaddresses this obstacle as well.

[0287] Once the programming has been completed as indicated by driver210 returning a value indicating the programming message contained avalid struct, PMPC 212 preferably generates an acknowledgement messagedirected to originator 200, indicating the programming has beenaccomplished. This message is provided to sync component 28 on mobiledevice 18 (and shown in FIG. 1). The next time the user connects mobiledevice 18 to the desktop computer 16, sync components 26 and 28cooperate to synchronize the acknowledgement message to desktop computer16. The next time desktop computer 16 accesses the originator 200 of theprogramming message, the acknowledgement message is transmitted to theoriginator 200 indicating that the programming has been accomplished. Inan emboidment in which desktop computer 16 is provided with a webbrowser, such as Internet Explorer 4.0, the acknowledgement message istransmitted back to the originator 200 when the web browser next invokesthe scheduler to establish an Internet connection with the originator.

[0288] Thus, it can be seen that the present invention provides adevice/protocol/network independent mechanism by which mobile device 18can be programmed. The present invention also provides a method ofencrypting data such that it can be sent in an encrypted and securedfashion from the originator 200 to mobile device 18. This mechanismallows the originator to program any suitable portions of mobile device18, including addresses, groups, keys, validity periods, and macrotags.The present invention also provides backchannel confirmation whichprovides the originator with an acknowledgement that the programming hasbeen accomplished.

[0289] Although the present invention has been described with referenceto preferred embodiments, workers skilled in the art will recognize thatchanges may be made in form and detail without departing from the spiritand scope of the invention.

What is claimed is:
 1. A programming interface on a mobile device fortransferring information to and from a radio receiver on the mobiledevice, the programming interface including: a message processingcomponent configured to receive messages to be delivered to the radioreceiver; and a driver component coupled to the message processingcomponent; wherein the message processing component is configured toexecute a control call to the driver component specifying a controloperation to be performed based on a message received, an input bufferlocation of an input buffer containing data to be transferred to theradio receiver, a number of bytes of information contained in the inputbuffer, an output buffer location of an output buffer containinginformation received from the radio receiver, a maximum number of bytesof information contained in the output buffer, and an actual number ofbytes received from the radio receiver; and wherein the driver componentis configured to receive the control call from the message processingcomponent and execute the specified control operation.
 2. Theprogramming interface of claim 1 wherein the control operation is aprogramming operation to program values in the radio receiver andwherein the control call passes a programming data structure to thedriver, the programming data structure including: a structure sizeportion indicative of a size of the programming data structure; a maskportion indicative of which portions in the programming data structureare valid; an operation code portion indicative of whether theprogramming operation is to program values or deprogram values; a typecode portion indicative of a type of values to be programmed ordeprogrammed; a program data portion indicative of the values to beprogrammed or deprogrammed; and a program data length portion indicativeof a length of the program data.
 3. The programming interface of claim 2wherein the type code portion is indicative of an encryption key to beprogrammed or deprogrammed and wherein the program data portioncomprises a key data structure.
 4. The programming interface of claim 3wherein the key data structure includes: a structure size portionindicative of a size of the key data structure; a mask portionindicative of which portions of the key data structure are valid; a keyportion indicative of the encryption key; a key number portionindicative of a number corresponding to the encryption key; an algorithmportion indicative of an encryption algorithm to be used in conjunctionwith the encryption key; a key length portion indicative of a length ofthe encryption key; a key tag portion indicative of a location in whichthe encryption key is stored; and a key tag length portion indicative ofa length of the key tag portion.
 5. The programming interface of claim 2wherein the mobile device receives messages over an address and whereinthe type code portion is indicative of an address to be programmed ordeprogrammed and wherein the program data portion comprises an addressdata structure.
 6. The programming interface of claim 5 wherein theaddress data structure includes: a structure size portion indicative ofa size of the address data structure; a mask portion indicative of whichportions of the address data structure are valid; an address portionindicative of the address; an address number portion indicative of anumber corresponding to the address; a status portion indicative of astatus of the address; an address tag portion indicative of a tagassociated with the address portion; an expiration date portionindicative of an expiration date associated with the address, whereinsubsequent messages received over the address after the expiration dateare discarded; and an address tag length portion indicative of a lengthof the address tag portion.
 7. The programming interface of claim 6wherein the address data structure further includes: a key tag portionindicative of a location at which an encryption key used to decryptmessages received over the address is stored; and a key tag lengthportion indicative of a length of the key tag portion.
 8. Theprogramming interface of claim 6 wherein the address data structurefurther comprises: an address name portion indicative of a descriptivename of the address; a description portion indicative of a textualdescription of messages received over the address; an address namelength portion indicative of a length of the address name portion; and adescription length portion indicative of a length of the descriptionportion.
 9. The programming interface of claim 2 wherein the mobiledevice receives messages over an address and a group code correspondingto the address and wherein the type code portion is indicative of agroup code to be programmed or deprogrammed and wherein the program dataportion comprises a group code data structure.
 10. The programminginterface of claim 9 wherein the group code data structure includes: astructure size portion indicative of a size of the group code datastructure; a mask portion indicative of which portions of the group codedata structure are valid; an group code portion indicative of the groupcode; an group code number portion indicative of a number correspondingto the group code; a status portion indicative of a status of the groupcode; an expiration date portion indicative of an expiration dateassociated with the group code, wherein subsequent messages receivedover the group code after the expiration date are discarded; a groupcode tag portion indicative of a tag associated with the group code; anaddress tag portion indicative of a tag associated with the address; anaddress tag length portion indicative of a length of the address tagportion; and a group tag length indicative of a length of the group tagportion.
 11. The programming interface of claim 10 wherein the groupcode data structure further includes: a key tag portion indicative of alocation at which an encryption key used to decrypt messages receivedover the group code is stored; and a key tag length portion indicativeof a length of the key tag portion.
 12. The programming interface ofclaim 11 wherein the group code data structure further comprises: agroup code name portion indicative of a descriptive name of the groupcode; a description portion indicative of a textual description ofmessages received over the group code; an group code name length portionindicative of a length of the group code name portion; and a descriptionlength portion indicative of a length of the description portion. 13.The programming interface of claim 2 wherein the mobile device receivesmessages over an address from a carrier and wherein the type codeportion is indicative of a carrier designation to be programmed ordeprogrammed and wherein the program data portion comprises a carrierdata structure.
 14. The programming interface of claim 13 wherein thecarrier data structure includes: a structure size portion indicative ofa size of the carrier data structure; a mask portion indicative of whichportions of the carrier data structure are valid; a frequency portionindicative of a radio frequency at which the messages are received fromthe carrier; a name portion indicative of a name of the carrier; adescription portion indicative of a description of message typesreceived from the carrier; a user identification portion indicative ofan identification number associated with a user of the mobile device; anuser identification length portion indicative of a length of the useridentification portion; a name length indicative of a length of the nameportion; and a description length portion indicative of a length of thedescription portion.
 15. The programming interface of claim 2 whereinthe radio receiver has existing values stored therein, whereinprogramming data portion comprises a programming data structure having aplurality of fields, each field corresponding to a value on the radioreceiver and each field containing new values to be programmed into theradio receiver, and wherein existing values on the radio receiver areleft unchanged when the field in the programming data structure does nothave a field corresponding to the existing value.
 16. The programminginterface of claim 1 wherein the wherein the driver component includes:a function library of functions performed by the driver in executing thespecified control operation.
 17. The programming interface of claim 16wherein the function library includes: an encryption key derivationcomponent for deriving an encryption key based on information providedto the driver component in the control call, wherein the drivercomponent utilizes the encryption key derivation component to derive theencryption key, stores the encryption key at a key location in thedriver component and returns a key handle indicative of the key locationto the message processing component.
 18. The programming interface ofclaim 16 wherein the function library includes: a decryption andvalidation component for decrypting and validating information providedto the driver component in the control call, the driver componentutilizing the decryption and validation component to decrypt andvalidate the information and returning a value to the message processingcomponent indicative of whether the information is valid.
 19. Theprogramming interface of claim 1 wherein the driver component isconfigured to return a value to the message processing componentindicative of whether the control operation specified by the controlcall has been performed.
 20. A computer readable medium on a mobiledevice, the computer readable medium having a first data structurestored thereon, the first date structure comprising: an addressinformation portion indicative of an address over which the mobiledevice receives messages; an address tag portion indicative of a tagassociated with the address portion; an expiration date portionindicative of an expiration date associated with the address, whereinsubsequent messages received over the address after the expiration dateare discarded; a key index portion indicative of a location on thecomputer readable medium storing an encryption key associated with themessages received over the address; and a status portion indicative of astatus of the address.
 21. The computer readable medium of claim 20wherein the status portion is indicative of whether the address isenabled.
 22. The computer readable medium of claim 20 wherein the statusportion is indicative of whether messages received over the address havea predetermined priority indicative of a time within which the messagesare processed.
 23. The computer readable medium of claim 20 wherein thestatus portion is indicative of whether a message received over theaddress are enabled only under predetermined power conditions.
 24. Thecomputer readable medium of claim 20 wherein the first data structureincludes: an address name portion indicative of a descriptive name ofthe address.
 25. The computer readable medium of claim 20 wherein thefirst data structure includes: a description portion indicative ofdescriptive text describing the messages received over the address. 26.The computer readable medium of claim 20 and further comprising a seconddata structure stored on the mobile device, the second data structureincluding: an encryption key portion indicative of an encryption keyused to decrypt a received message; an encryption algorithm portionindicative of an encryption algorithm used to encrypt the message; and akey tag portion indicative of a key tagassociated with the encryptionkey.
 27. The computer readable medium of claim 26 and further comprisinga third data structure stored on the mobile device, the third datastructure including: a service group code portion indicative of aservice group code over which the mobile device receives messages; astatus portion indicative of a status of the service group code; a keyindex portion indicative of a location on the computer readable mediumwhich stores an encryption key associated with the messages receivedover the service group code; an expiration date portion indicative of anexpiration date associated with the service group code, whereinsubsequent messages received over the service group code after theexpiration date are discarded; and a service group tag indicative of atag associated with the service group code.
 28. The computer readablemedium of claim 27 wherein the mobile device includes a radio receiverand wherein the first, second and third data structures are stored onthe radio receiver.
 29. A computer readable medium on a mobile device,the computer readable medium having a data structure stored thereon, thedata structure comprising: an encryption key portion indicative of anencryption key used to decrypt a received message; an encryptionalgorithm portion indicative of an encryption algorithm used to encryptthe message; and a key tag portion indicative of a key tag associatedwith the encryption key.
 30. The computer readable medium of claim 29wherein the mobile device includes a radio receiver and wherein the datastructure is stored on the radio receiver.
 31. A computer readablemedium on a mobile device, the computer readable medium having a datastructure stored thereon, the data structure comprising: a service groupcode portion indicative of a service group code over which the mobiledevice receives messages; a status portion indicative of a status of theservice group code; a key index portion indicative of a location on thecomputer readable medium which stores an encryption key associated withthe messages received over the service group code; an expiration dateportion indicative of an expiration date associated with the servicegroup code, wherein subsequent messages received over the service groupcode after the expiration date are discarded; and a service group tagindicative of a tag associated with the service group code.
 32. Thecomputer readable medium of claim 31 wherein the data structurecomprises: a service group name portion indicative of a descriptive namefor the service group code.
 33. The computer readable medium of claim 31wherein the data structure comprises: a description portion indicativeof descriptive text describing messages received over the service groupcode.
 34. The computer readable medium of claim 31 wherein each servicegroup code they have associated addresses and are stored in a locationarranged according to the address and then according to service groupcode.
 35. The computer readable medium of claim 31 wherein the mobiledevice includes a radio receiver and wherein the data structure isstored on the radio receiver.
 36. The computer readable medium of claim31 wherein the computer readable medium includes a key table and whereinthe key index is indicative of a location in the key table which holdsthe encryption key.
 37. A transmission system for transmittinginformation from an originator to a mobile device, the transmissionsystem comprising: an originator component configured to receive theinformation to be transmitted and form a transmission message; and areceiver component configured to receive the transmission message;wherein the originator includes: a first encryption key componentconfigured to derive a first encryption key based on a base key known bythe receiver component, a first data string and a data portion includingmessage specific data derived from the information to be transmitted; asecond encryption key component configured to derive a second encryptionkey based on the base key, a second data string and the data portion; anencryptor configured to hash the information to be transmitted with thefirst encryption key to obtain a signature and to encrypt theinformation and the signature with the second encryption key to obtainan encrypted message; and a joiner configured to join the encryptedmessage with the message specific data, in unencrypted form.
 38. Thetransmission system of claim 37 wherein the originator comprises: aheader generation component configured to receive the encrypted messageand message specific data and add a header thereto to obtain thetransmission message.
 39. The transmission system of claim 37 whereinthe first encryption key component hashes the base key, the first datastring and the message specific data to obtain a bias value and whereinthe first encryption key component includes: a key generator configuredto receive the bias value and generate the first encryption key based onthe bias value.
 40. The transmission system of claim 37 wherein thesecond encryption key component hashes the base key, the second datastring and the message specific data to obtain a bias value and whereinthe second encryption key component includes: a key generator configuredto receive the bias value and generate the second encryption key basedon the bias value.
 41. The transmission system of claim 37 wherein theoriginator includes: a checksum component configured to calculate achecksum over the transmission message and append the checksum thereto.42. The transmission system of claim 41 wherein the receiver componentcomprises: a processor component; and a driver component coupled to theprocessor component; wherein the processing component is configured toreceive the transmission message and pass the transmission message tothe driver component, the driver component being configured to derivethe first and second encryption keys from the based key, the first andsecond data strings and the message specific data and decrypt thetransmission message.
 43. The transmission system of claim 42 whereinthe driver component further comprises: a validation componentconfigured to calculate a checksum over the unencrypted transmissionmessage, and compare the checksum calculated to the checksum calculatedby the checksum component to determine whether the unencrypted messageis valid.
 44. The transmission system of claim 37 wherein the mobiledevice includes a radio receiver having values stored therein, thevalues determining operation of the radio receiver, and wherein thetransmission message comprises a programming message for programming thevalues in the radio receiver.
 45. A wireless transmission system fortransmitting programming data to a mobile device having a one-way radioreceiver thereon, the transmission system including: an originatorcomponent configured to receive the programming data and form aprogramming message indicative of the programming data; a transmittercomponent, selectively coupleable to the originator, configured totransmit the programming message to the mobile device; a mobile deviceprocessing component configured to receive the programming message andprovide it to the radio receiver and to provide an acknowledge messagein response to successfully providing the programming message to theradio receiver; a mobile device synchronization component coupled to themobile device processing component; a desktop computing deviceselectively coupleable to the mobile device and including a desktopsynchronization component operable with the mobile devicesynchronization component to synchronize the acknowledge message to thedesktop computing device; and a desktop communication componentselectively coupleable to the originator and configured to pass theacknowledge message to the originator.
 46. The wireless transmissionsystem of claim 45 wherein the transmitter component comprises: anoriginator communication component selectively coupleable to the desktopcommunication component and configured to transmit the programmingmessage to the desktop computing device for synchronization to themobile device processing component.
 47. The wireless transmission systemof claim 45 wherein the transmitter component comprises: a radiotransmitter configured to broadcast the programming message to the radioreceiver.
 48. The wireless transmission system of claim 45 wherein thetransmitter component comprises: a modem configured to transmit theprogramming message to the radio receiver.
 49. The wireless transmissionsystem of claim 45 wherein the transmitter component comprises: aportable magnetic storage medium, readable by the mobile deviceprocessing component, storing the programming message.
 50. The wirelesstransmission system of claim 45 wherein the desktop communicationcomponent comprises a global computer network browser.